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ABSTRACT: A crucial action of COVID-19 combat is the quick design and building of makeshift hospitals (MHs). 
Although adopting building information modeling (BIM) promotes the digitalization and communication of design 
collaboration, data security vulnerabilities (e.g., lacking traceability and transparency) are detected and have 
inevitably impeded the efficiency and productivity of the MH project. Such problems often lead to rework and 
unnecessary disputes, wasting valuable time on projects requiring ultra-fast construction speed. The emerging 
blockchain technology offers an immutable and traceable collaboration environment. However, limited studies 
have integrated blockchain in the BIM design process, especially design in emergency projects like MH. Therefore, 
this paper proposes a blockchain-enabled collaboration (BEC) framework for fast and secure BIM design. The 
framework is illustrated in an actual MH project in Hong Kong, and results show that: (1) it supports secure and 
automated BIM data exchange and (2) it saves 23 % of the time in a design coordination case. 
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1. INTRODUCTION 


The COVID-19 pandemic seriously threatens the global public medical and health system. By January 2023, there 
had been over 750 million confirmed illnesses and over 6 million documented fatalities (WHO, 2023). 
Governments launched many emergency construction projects to meet the enormous demand for patient quarantine 
facilities, establishing multiple makeshift hospitals (MHs) (Luo et al., 2020). A makeshift hospital, also referred 
to as Fangcang hospital or mobile cabin hospital, is a type of emergency service that assembles modular medical 
units to form a temporary hospital to address the ongoing scarcity of medical supplies. Two examples in China, 
Huoshenshan hospital and Leishenshan hospitals, built and delivered in 10 days and 18 days, respectively, have 
proved that the suppression of epidemic outbreaks is made possible by establishing temporary MHs, which are 
crucial for lifesaving and improving recovery rates (Zhou et al., 2022). 


MHs have challenging tasks, intricate specifications, and condensed design and build times. Therefore, building 
information modeling (BIM) technology is introduced because these criteria present additional difficulties for 
design work (Tan ey al., 2021). BIM is essential in streamlining coordination by combining organizational and 
procedural data into a shared repository. According to (Luo et al., 2020), BIM benefits the MH design in three 
aspects. First, MH design needs significant optimization work by reducing changes during the building phase by 
visualizing all conflicts. Additionally, designers can use integrated BIM data to speed up construction for parallel 
scheduling, improving design simulation, like predicting the transmission of viruses in negative pressure wards. 
Finally, BIM is a platform everyone can use to easily create, exchange, and collect digital data to promote 
collaboration. 


However, some data security concerns still exist in the MH BIM process, causing reworks and time waste, 
hindering efficiency and productivity. For example, in contrast to general construction projects in which BIM 
models from various disciplines are created sequentially, models in MHs are made independently and concurrently. 
When BIM information is synchronized amongst teams, there is a danger of data omission and inconsistency, 
which eventually leads to design errors because there are no referenced models for the untransparent collaborative 
environment. Besides, there are no routine meetings for BIM coordination due to time constraints. Instead, a "peer- 
to-peer (P2P)" communication model is used, wherein project members contact accountable designers directly and 
personally through virtual meetings or phone calls. However, because it lacks verifiable and traceable records, this 
method can occasionally be disorganized and ineffectual, making collaboration time-consuming. 


Blockchain is a distributed database technology that leverages peer-to-peer networks, cryptographic hash 
algorithms, and consensus mechanisms to secure data integrity (Tao et al., 2020). The blockchain prevents a single 
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administrator from controlling the entire network because each peer keeps an identical and append-only data copy 
(also known as the blockchain ledger). The benefits of blockchain in construction payment (Das et al., 2020), 
supply chain management (Tezel et al., 2021), and design collaboration (Pradeep et al., 2021) have been 
preliminarily investigated. However, incorporating blockchain into MHs is still in its infancy for two barriers: (1) 
The mechanism of embedding blockchain in an MH BIM process is unclear. Problems like which activities need 
blockchain and what data should be transferred are still awaiting solutions. (2) Key technical elements, like smart 
contracts supporting blockchain data interaction, have not been developed. 


Therefore, this paper proposes a blockchain-enabled collaboration (BEC) framework for fast and secure BIM 
design. The primary scientific contributions of this paper are: (1) identified three main security risks in the MH 
BIM design process, (2) proposed a BEC framework to alleviate harms brought by the security issue, thus 
improving design efficiency, and (3) developed three smart contracts to automate the data exchange in a blockchain. 
Finally, the framework is demonstrated and evaluated in an actual MH project in Hong Kong. 


2. METHODOLOGY 
2.1 Identification of BIM security vulnerabilities in MH 


Locating the risks is the fundamental step in developing the BEC framework. In this study, one BIM manager and 
two BIM designers who had a direct hand in an MH project and were familiar with the intricate steps of BIM- 
based design were interviewed four times each. Data collection took place over one month in 2022, from March 
to April. A BIM collaborative design workflow is in Figure 1. 
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Fig. 1: BIM-based design workflow in MH 


Three factors account for how the workflow quickens the BIM design process. The parallel design is the first 
benefit. Several models are produced simultaneously in this MCH project, reducing time compared to normal 
construction projects in which BIM models from several disciplines are developed sequentially. P2P 
communication is the second advantage. There are no scheduled meetings for BIM coordination because of 
scheduling constraints. Instead, a P2P communication model is used, in which accountable designers are contacted 
directly and personally by project members during virtual meetings or phone calls when design issues arise. This 
is an effective method for facilitating communication since it prevents pointless meetings and enables responsible 
individuals to identify design concerns promptly. Pre-revision refers to addressing design or BIM model issues 
before the client issues formally amended drawings or documentation, saving waiting time. Content marked green 
in Figure 1 indicates the steps that can be improved by blockchain. 


However, security flaws are also caused by such unique collaboration methods. The risks and merits provided by 
blockchain are presented in Figure 2. For parallel work, the absence of a visible path for updating information 
causes differences across models, mistakes in design, and even delays. Blockchain guarantees data transparency 
and consistency thanks to its distributed architecture. In the course of the discussion, the BIM manager bemoaned 
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the fact that they frequently wasted time looking up design records to identify problems because ECPs lacked 
adequate logging facilities, leaving out certain previous data. Additionally, several designers collaborate to develop 
a model in a "relay race" fashion, with each team member finishing a section of the model in turn. The designer 
contacted during the P2P collaboration may not be aware of the specifics of the issue if they recently took over the 
contract from another designer (the issue proposer). All design logs and actions can be immutably recorded using 
blockchain to improve collaboration traceability. 
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Fig. 2: Blockchain merits in MH 
2.2 Blockchain-enabled collaboration (BEC) framework 


Pre-revision requires permissions from multiple 
parties. Physical signing is time-consuming, and 
it is hare to verify signature authenticity 


The BEC framework in Figure 3 shows the logic of implementing blockchain in an MH BIM design and offers a 
technical stack for data flow. The seven-layer architecture serves as an example of the technical stack used to create 
a BEC framework. Through the application layer, which provides an interface for user management, users in the 
user layer can sign up for the blockchain. User operations may be documented in the blockchain in this manner. 
These "one-stop" registration processes make it easier for consumers to use blockchains because they simply need 
to complete standard registration processes. The interaction between the front-end inputs and the blockchain 
databases on the backend is carried out through smart contracts at the smart contract layer. Blockchain smart 
contracts, machine-readable pieces of code, can self-execute business logic (e.g., payment) on blockchain ledgers, 
thus empowering automatic and unforgeable collaboration actions (Li et al., 2022). Event transactions will 
represent collaboration actions, such as permission transactions (metadata of permission execution), issue event 
transactions, and model event transactions (metadata of events pertaining to BIM models). Large-sized data like 
BIM models and non-graphic documents are also stored in off-chain databases, which can be local servers or cloud 
servers like Autodesk BIM 360. This is in addition to on-chain data (transactions). This layer has a digital signature 
generator that generates digital signatures using the 256-bit secure hash technique (SHA-256). These fingerprints 
are spread across the blockchain network. The infrastructure layer serves as the foundation and provides necessary 
services, including cloud data storage, operating systems, and hardware (e.g., GPU and CPU). 
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Fig. 3: Architecture of BEC framework 
2.3 Smart contracts for BIM data interaction 


In the BEC framework, three smart contracts have been coded. The pseudocodes are shown in Figure 4. A 
transaction comprising the model ID, fingerprint, user ID, and timestamp will be transmitted to the IS (information 
sharing) smart contract whenever a user uploads a new model (or issue). An endorsing node will verify this 
transaction by examining the legality of the transaction (Step 1). Illegal transactions will be denied, or they can go 
through and be sent back to the smart contract with endorsing signatures. An example of an illegal transaction 
would be one where the transaction data model is not required to follow a key-value structure (Step 2). In Step 3, 
the smart contract hands the transaction off to an ordering service that will chronologically group the transactions 
that occurred within the specified time into a new block. All blockchain nodes will receive it through the smart 
contract, and upon obtaining it, they will verify the block (Steps 4 and 5). The ledger will be updated with 
confirmed blocks as immutable records. 


The rationale behind PE (permission execution) smart contracts is similar. One distinction is the smart contract 
input, and the other is the status results. After reviewing an issue, a project member (such as a domain manager) 
can decide. An endorsing peer will receive a new transaction from the PE smart contract along with all essential 
metadata (such as issue ID, issue decision, reviewer comments, etc.) so they can verify that the input complies 
with the regulated data model. Then, the project member will update the blockchain world state, a database that 
displays the most current status of various files and is built on top of the blockchain ledger. Besides, the PE smart 
contract creates and stores the digital signatures of the user to ensure the integrity of outcomes, saving time by 
doing away with the laborious physical permit process. The HQ (history query) smart contract will retrieve 
previous transactions (e.g., file ID) based on the provided key. 
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Pseudocode of information sharing (IS) smart contract 
Input: IS transaction data, IS function 
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15 if validation results = true 

16 return new block € block number “N+1” 

17 notification message € “Transaction has been successfully shared” 
18 else 

19 IS transaction sharing fails 

20 Step 6: Notification 

21 End 


Pseudocode of permission execution (PE) smart contract 


1 Input: PE transaction data, decision, PE function 

2 Output: New block in blockchain, issue status change 

3 Step 1: PE function proposes the transaction for legality checking 

4 if input data model = pre-defined PE data model 

5 Function name = PE 

6 generate endorser signatures 

T else 

8 validation fails 

9 Step 2: Get back endorsing signature 

10 return pre-execution results € transaction data||read-set||write-set||signatures 
11 Step 3: Sent to ordering service for new block packing 

12 new block € pre-execution results||block hashes||Merkle tree||timestamp 


13 Step 4: Broadcast the new block to all nodes 
14 Step 5: Verify and add to ledger 


15 if validation results = true 

16 return new block € block number “N+1” 

17 notification message € “Transaction has been successfully shared” 
18 New issue status € reviewer ID||decision 

19 else 

20 PE transaction sharing fails 

21 Step 6: Notification 

22 End 


Pseudocode of history query (HQ) smart contract 

1 Input: Target file ID, HQ function 

2 Output: Transactions details of a given ID 

3 Step 1: HQ function checks if the given ID exists in blockchain 
4 if ID exists 

5 query results € transaction value of this given ID 

6 

7 
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else 
reject the query 
End 


Fig. 3: Architecture of BEC framework 


3. VALIDATION AND EVALUATION 
3.1 Validation scenario 


The roadmap for the validation scenario, which aims to confirm the viability of the smart contract and the 
authorization workflow, is shown in Figure 5. The AR-01 presents a concern regarding the current window size of 
a medical block, which is 600*1200mm, although the standard suggests a 900*1200mm window. The problem is 
then generated, along with a design document, for review. The domain team leader AR-O reviews the issue detail 
and approves it with the remark that "this is an issue." The technical engineer (TE-1) notes that this problem cannot 
be resolved internally and requires the client's additional input. The quality manager (QM-1) approves this issue 
because it relates to requirements that should be accepted by the client and drawing team. All these permissions 
are carried out by calling the PE smart contract. Results indicate that every authorization action was carried out 
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automatically and stored in the blockchain. Each transaction records the following information: (1) the user ID 
executing the action, (2) the judgments (in this case, "approved") made by various users, and (3) the precise 
remarks made by various parties. 


' ” . . . 
ı “AR-01” raised an issue that the window size of a 
| medical module does not comply with standards 


Issue form 


lem form 


“Currgnt window size is 600*1200mm, 
Howeyer, according to the Guide for í 
mobil cabin hospital design and i 
construction, a 900*1200mm window is | | 
suggested.” i 

i 


“Status: Approved 


i ma e by domain leader” Pramana “Status: Approved by menemme “Status: Approved by 
' k g technical engineer” r quality manager” 
; o> aan =, 

a i “User ID: TE-1” ; “User ID: QM-1” 


Fig. 5: Framework validation in a BIM permission execution scenario 


3.2 Framework evaluation 


The evaluation includes two parts. The first is BEC computing performance testing, aiming to see if the proposed 
framework meets the basic data processing requirements. High latency, like what is in the Bitcoin blockchain, is 
not acceptable in construction design. The second is a comparison evaluation to test if the BEC framework 
advances existing BIM solutions regarding design efficiency. 


Blockchain latency measures the time required for a smart contract to register a transaction in the blockchain 
(Ciotta et al., 2021). To determine whether a blockchain's "speed" meets business needs, latency is a crucial statistic 
in the evaluation process. In MHs where rapid information sharing is required, high latency is problematic. The 
latency of three smart contracts is measured in this research. To prevent abnormal findings, the repeated test is run 
ten times. The results in Figure 6 demonstrate that all latency is millisecond-level. No latency standard has been 
established in construction, because the blockchain is currently being built. Consumers won't notice the delay if 
the blockchain application's maximum reaction time is less than 1 second, according to Fatokun (2021). 
Recommendations and best practices from studies (Sheng et al., 2020; Tao et al., 2021) state that millisecond-level 
blockchain latency is acceptable for design and construction procedures. The BEC framework latency is, therefore, 
permissible. 


The quantitative analysis of how automated smart contracts in the BEC framework could promote efficiency is 
shown in Figure 7. Three project participants from the MH project—one BIM manager and two designers—were 
requested to conduct a BIM design coordination case in both the current BIM 360 platform and the prototype based 
on the BEC framework. Because the BEC framework employs a workflow like current practice, the time 
investment in the initial model change is the same (30 mins). The model adjustment required the design team to 
review previous data. The retrieval of a CAD drawing's change history took 11 minutes due to inadequate 
traceability in traditional solutions. The BIM team only spent 3 minutes identifying all BEC framework traceable 
blockchain ledger records thanks to the HQ smart contract. Both solutions required P2P collaboration and took 8 
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minutes. The team leader had to sign a design sheet before it could be pre-revised. The current method required 
10 minutes to obtain a physical signature (including the waiting time). In contrast, calling the PE smart contract in 
BEC took 6 minutes. The BIM team also had to do extra work since they missed a supplier update because they 
were working on a different system; as a result, they had to spend an additional 10 minutes using existing solutions 
to fix the problem. Finally, by utilizing BEC and smart contracts (72 min in total), 23% of the time was reduced 
compared to the current solution (94 mins in total) 
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Fig. 6: Latency of BEC framework 
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Fig. 7: Comparison results of a BIM coordination scenario 
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4. CONCLUSION 


BIM-based design in MHs risks data security issues that will impair job productivity due to stringent time 
constraints and complex design processes. Therefore, this study proposes a BEC framework to increase the design 
efficiency of ECPs while lowering the obstacles to accessing blockchain benefits. Three objectives have been 
achieved. Firstly, through interviewing BIM participants from an MH project, three risks, namely, lacking 
transparency, lacking traceability, and lacking permission automation, that will harm the design process are 
identified. Secondly, a BEC framework is presented to show the technical architecture to guide the data exchange 
and BEC prototype development. Third, three smart contracts are developed for secure information sharing, 
permission execution, and historical data query. Due to time and technological limits, there are still restrictions on 
this early exploration. Non-automatic data verification comes first. The blockchain ledger generates and records 
data fingerprints. The verification procedure is still manual, though. Further research is still required on 
automatically comparing a file with its fingerprint. 
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